﻿<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
	<head>
		<title></title>
	</head>
	<body>
	<H1>IRC Operators Guide</H1> 
 
by Aaron Brinton aka aaronb v1 8/97<BR> 
HTML translation by Joseph Lo aka <A HREF="/~jyl/mail.cgi">Jolo</A> 9/97<P> 
 
<BLOCKQUOTE><SMALL> 
Ed. note: This guide offers a fascinating glimpse into the
&quot;Twilight Zone&quot; world of IRC operators, also known as IRC ops
or opers. This has very little to do with channel ops or the maintenance
of a chat channel. The guide is written by an oper ostensibly for other
opers, but its real audience is the average user. For other help files
regarding IRC ops or running servers, see the <A 
HREF="/irchelp/ircd/">IRCd server directory</A>. -Jolo<P> 
</SMALL></BLOCKQUOTE> 
 
<HR> 
 
	The objective of this document is to provide some basic operator
notes from my perspective.  I've found that asking opers questions
usually results in nothing more than smart-ass answers, which I think is
a little sad.  I'm a relatively new operator (under two years), so
please understand that I'm not an ordained expert on this material, and
that some of the information may only apply to my network (EFnet).  If
you find errors in here, either typographical or conceptual, please let
me know. <P> 
 
	Note:  There will be personal views in here, but I'll try to
keep them to a minimum. <P> 
 
<HR> 
 
<H2>Contents</H2> 
 
<PRE> 
   I. Interacting with Users and Other Operators
  II. Using KILL and KLINE
 III. Bots and Bothunting
  IV. Cloners, Flooders, and Spoofing
   V. Why Operators (Usually) Don't Get Involved In Channel Affairs
  VI. Dealing with "How Does One Become an IRC Operator?"
 VII. IRCD and Associated Files
VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)
  IX. Server Routing and Connectivity
   X. Other Server Commands (REHASH, RESTART, and DIE)
  XI. Operator Communications (WALLOPS and OPERWALL)
 XII. Linking New Servers
XIII. Attitude and Perspective
</PRE> 
 
<HR> 
 
<H2>I. Interacting With Users and Other Operators</H2> 
 
	This is the most important aspect of "opering".  It will make or
break you as an operator.  There are a lot of politics that go on in the
irc operator community and, whether you like it or not, these politics
are here to stay.  Fighting this and complaining about it will get you
nowhere. <P> 
 
	From what I've seen, most opers look down on users, make fun of
them, and ignore them.  Try to avoid this ego trip side of opering. 
Answer private messages, unless it is someone just sending you a hate
message. Opers would get a lot less crap from users if they would be a
little less egotistical.  Something I might suggest is that you spend an
hour or two every couple of weeks helping the newbies out in #irchelp or
whatever equivalent you may find. <P> 
 
	One thing to be wary of is that users will frequently try to
manipulate you into helping them takeover channels.  Very rarely will a
user simply report a bot without a reason.  Generally this will be
because a bot tookover a channel or a user is flooding them.  Fairly
regularly you'll get these requests from users who want someone killed
off the server so they can take control of a channel. Because of this,
request the channel in addition to the nickname so you can see what's
going on before you kill or K-line. <P> 
 
	Frequently, you will get requests from other operators to kill
or K-line a user.  Opers should be trusted unless you've had problems
with someone in the past.  You should always require a reason before
killing or placing the K-line.  If it's in the least bit questionable,
add "requested by &lt;oper&gt;" or something similar to the K-line
reason.<P> 
 
	If you are being harassed by a user on the network, handle it
like a user should handle it, not like an oper has the capability of
handling it. The temptation of killing a user for flooding you is
something that pretty much all of us give into on occasion, but it's
generally not the right response.  If we are going to expect regular
users to simply /ignore flooders, then we should do the same.  Though I
have to admit, a user must be pretty stupid to flood an oper...<P> 
 
	On occasion, opers have their disagreements.  There is a bit of
a pecking order that exists in the oper ranks, usually with hub admins
and opers being more "powerful" than leaf admins and opers.  It's
generally not a good idea to try to win an argument with the people who
are providing your connectivity to the IRC network.  For that matter,
it's generally not a good idea to try to win any argument at all.  If
you do have a serious problem with another oper, and can't resolve it
directly with him/her, go to your admin about it.  Your admin can then
approach the issue with the other oper's admin, and if that goes
nowhere, with their uplink admin. This is a quick way to make enemies,
so make sure it's important to you before doing it.<P> 
 
<HR> 
 
<H2>II. Using KILL and KLINE</H2> 
 
The KILL and KLINE commands are as follows:<BR> 
<BLOCKQUOTE> 
	KILL nick :reason<BR> 
	KLINE nick :reason<BR> 
	KLINE username@hostmask :reason<BR> 
</BLOCKQUOTE> 
 
	In my K-lines, I always use "reason [aaronb MM/DD/YY]" so that
the user knows when and by whom they were K-lined, and also so that I am
accountable for my K-lines. <P> 
 
	Generally, whatever you do on your local server really is not a
big deal.  Different servers have different policies on using KILL and
KLINE, but if you are doing global kills (killing a user on a different
server), you need to make sure you understand what the IRC network's
guidelines are. <P> 
 
	Users tend to have one of two reactions to kills.  Occasionally
you'll get the user to cool off and realize that they need to fix
whatever they are doing.  More often, they will want to argue the point
with you.  Try to explain it to them, but if they don't seem to be
willing to follow the server guidelines, just K-line them.  After they
get K-lined from a few servers, they'll figure it out. <P> 
 
	You probably want to avoid K-lining users unless it's really
necessary. A K-line means that you don't want that user on your server,
for whatever reason.  Depending on the server, K-lines may be cleared
after a week or two, a few months, or maybe never.  It might be wise to
have a &quot;permanent&quot; section of K-lines, and then the rest can
stay or go at anyone else's discretion.  For clearing K-lines, generally
it's a good idea to talk to the person who placed it before doing so.
With access to ircd.conf (to remove K-lines), you can be a lot less
cautious about placing them. <P> 
 
	The best guideline for doing global kills is to ask yourself
&quot;Is this really necessary?&quot;  You can usually find an oper on
the server the user is on to handle an issue for you instead.  If an
oper on the server won't do it, then probably they wouldn't like you
killing the user off their server either. <P> 
 
	Frequently it seems that opers are just looking for a reason to
kill. Probably if you are in that mood, it would be a good time to
deoper and go find something else to do for a while.  Killing like that
looks bad for both you and for your server. <P> 
 
	It's a wise idea to keep logs of everything you do.  I have yet
to see a client that doesn't have the capability of logging.  If a user
or another oper challenges your kill (usually to your admin, since they
typically don't have the guts to talk to you), you can provide them. You
will most likely be accused of abusing your O-line, and threatened by
users to get it taken away, on a regular basis.  Logs are your best
defense. <P> 
 
<HR> 
 
<H2>III. Bots and Bothunting</H2> 
 
	A "bot" generally refers to any automated program or client that
doesn't have a person sitting behind it, not just a program that is
called one. If a client is idle for several hours and is behaving like a
bot, it's usually considered one. <P> 
 
	There are a couple of reasons why bots are frequently considered
to a problem.  First, they take up resources on IRC that could be used
for regular client connections.  The primary reason, though, is because
bots are frequently used to flood and harass users.  You'll want to
check what your server's policies are regarding bots, but an abusive bot
should never be tolerated. <P> 
 
	Finding bots generally isn't that difficult.  Many have ctcp
responses that don't match what you would expect, or have bogus idle
times (in their ctcp finger response).  Also, there are a couple of good
portscanners that can help you check hosts for bots (eggdrop bots
usually listen on a port for incoming telnet connections). <P> 
 
	You probably aren't going to find all the bots being run by hardcore
botrunners.  They generally find out quickly about whatever new
bothunting methods we come up with and spread the word.  With these,
your best bet is to wait until someone complains about it, and then
monitor its behavior. <P> 
 
	Here is a short description of a few of the bots out there, and
a couple of tips for finding them:<BR> 
 
<UL> 
	<LI> eggdrop - this is the most common bot that you'll run into.
Typically you'll see "/msg botnick hello" in the gecos field (the
description line in the whois information) if the bot is poorly
configured. Additionally, by default, these bots PRIVMSG #lamest for
invite/ops.  They also join #botcentral by default.
 
	<LI> johbot - these bots PRIVMSG blahb1ah on a regular basis. 
If you change your nickname to that, you can sit and wait for them to
find you. Additionally, if you enter the channel a suspected johbot is
in, and do a fake netsplit quit (/quit irc.blah.com irc.something.net),
the johbot will automatically change its nickname.
 
	<LI> combot - these are a comstud creation.  I have never found
one myself, which either means there aren't many around, or they just
hide really well.  I've heard that doing a /ctcp botnick source will
generate a reply with "Combot" followed by the version.
</UL> 
 
	There are other methods of finding bots, but they change far too
regularly for this document.  Also, we don't need to be giving the
masses out there all of our secrets.  Keep in touch with other opers on
this stuff. <P> 
 
<HR> 
 
<H2>IV. Cloners, Flooders, and Spoofing</H2> 
 
	Clones are multiple clients from the same person.  Most servers
define this as multiple connections from the same hostmask (matching
user@*host.tld).  If it's obvious someone is running multiple clients
from different domains, they are also considered clones.<P> 
 
	Generally, cloning itself is not all that bad (just taking up
connections).  Frequently when you see clones, however, they are being
used to flood users or takeover channels.<P> 
 
	The best approach to take with clones is to kill them, and see
if they return.  If you do this a couple of times, and the user insists
on keeping them on, it's time for a K-line.  Unless a user is
consistently a problem, clone K-lines should be relatively temporary (a
few weeks is sufficient).<P> 
 
	You'll see two forms of flooding on IRC.  The first is CTCP
flooding, which attempts to get a user to flood the server with CTCP
responses, tripping the server's flood protection, and terminating the
user with the message "Excess Flood".  Many bot networks ("fludnets")
use this type of flood.  Flood protection scripts may prevent this from
being very effective, but the real problem is the impact on the network.
 If 20 bots flood a user for 10 seconds, sending five 100 byte CTCP
requests per second, that is 20 * 100 * 5 = 10k/sec, or 100k of data
total over the 10 seconds.  When a network that is maintaining 30000
users, this sort of activity is not at all acceptable.<P> 
 
	The second type of flooding, which is not related to IRC (but is
frequently the result of conflicts on IRC), is ICMP flooding.  This is
usually done from a reasonably fast link (ISDN or higher) and consists
of flooding a user or server with ICMP packets (such as ping).  This is
considered a "Denial Of Service" attack, and is against the law.<P> 
 
	There are many flooding scripts out there right now, and a couple of
these have supposedly "random" nicknames they use for CTCP flooding.  A
trick to use is to set a couple of those nicks in your notify.  Some
flooding scripts also have the clones join specific channels (e.g.
#srfloodclones).<P> 
 
	DNS spoofing is a relatively new hit these days on IRC.  You'll
generally find spoofs one of two ways - you're watching the connections
(usermode +c) and an unusual hostmask appears, or a user reports one. 
The first thing to do is to get the user's IP address (/stats L nick),
and check to see if the DNS lookup matches the IP address.  If it
doesn't, you know you have a spoof.  With this information, you can KILL
the spoof, and when it reconnects, see where the real host is and issue
a K-line (which won't stop them from spoofing again, but will prevent
them from signing on *without* spoofing).  Some servers have the
capability of D-lines, which allow you to ban by ip mask.  A D-line will
prevent the client from connecting at all, regardless of whether they
try DNS spoofing or not.  If the server supports the DLINE command, you
can do /dline ipmask :reason.<P> 
 
 
<HR> 
 
<H2>V. Why Operators (Usually) Don't Get Involved In Channel Affairs</H2> 
 
	The primary function of opers is to maintain the servers and the
network, not to deal with channels.  The main reason the general policy
is for opers not to get involved is because it is frequently difficult
to determine who really should be controlling a channel.  There are a
lot of deceitful users out there that will ask you to help them get
their channel back when it is not their channel in the first place. 
Even if you do know who the regular ops are, oper involvement is
questioned and challenged, so many opers will ignore channel issues
entirely just to save the grief.<P> 
 
	In practice, you'll find opers defend their own channels, and
turn their backs on others.  It's a little pathetic, but after you get
harassed enough by users saying "why are you getting involved?  I
thought opers weren't supposed to get involved in channel affairs"
you'll start to understand the cynicism.<P> 
 
 
<HR> 
 
<H2>VI. Dealing with "How Does One Become an IRC Operator?"</H2> 
 
	Most users have no comprehension of what opering involves, and
really have no place becoming one.  This does not mean, however, that
they deserve an abusive answer or to be blown off when asking how to
become an operator. It's easy to set up a simple alias to provide an
automated response to this question.<P> 
 
	For example, use an alias like &quot;Becoming an IRC Operator
requires not only a strong working knowledge of IRC and this IRC
network, but also a working relationship with hub admins and other
opers.  Opers are selected when there is a need, and never given based
on who is asking for it.&quot;<P> 
 
	The thing to remember is that there are always going to be more
people that want to be an operator than there are openings.  If you
really want to help the network, the best way to do it is by answering
new user questions on channels like #irchelp and #help.<P> 
 
 
<HR> 
 
<H2>VII. IRCD and Associated Files</H2> 
 
	IRCD is the server daemon process.  The large IRC networks will
only allow unix-based servers, because they are the only ones proven to
perform adequately on a large network (and because the current set of
operators are mostly unix bigots... including myself to some degree). 
EFnet uses modifications of the 2.8.2 version; IRCnet uses modification
of the 2.9.x versions.<P> 
 
	The installed file structure varies from server to server, but
you should have at least these two primary files:<P> 
 
<PRE> 
	ircd			the IRC server daemon (main program)
	ircd.conf		the server configuration file
</PRE> 
 
	The configuration file has various configuration items in it,
which are in a format beginning with a letter and a colon.  This file is
read and processed backwards, so when you do STATS commands (described
later), you'll see the information in the reverse order of the entries
in ircd.conf.	This file has the following configuration lines in
it:<P> 
 
<DL> 
 
	<DT>A:Company/Institute Name:Server Description:Admin Name
&lt;email@address.com&gt;<P> 
 
	<DD>This configures the administrative functionality of the server,
which is returned when a user does /admin on your server.  The fields
are completely up to the administrator of the server, but what I put
above seems fairly standard.  This is a mandatory field.<P> 
 
	<DT>B:hostmask::nick::<P> 
 
	<DD>This line indicates a permitted bot.  The server has built-in
bot checking for certain known instances of bots, and will refuse the
connection if it detects one.  If the bot has this line in the config
file, the server will not refuse the connection.<P> 
 
	<DT>C:server hostname:password:server name:port:connection class<BR> 
N:server hostname:password:server name:hostmask:connection class<P> 
 
	<DD>C/N-lines are connections to other servers.  The C-line defines
what servers your server can connect to, and the N-line defines what
servers your server allows incoming connections from.  I have never seen
one without the other, and according to the sample ircd.conf, they must
be used in pairs.  The server hostname, password, and servername are
fairly self explanatory.  The port is used to identify which port your
server will try to connect to automatically; if the port field is blank,
your server will not automatically attempt to connect to that server.  I
have never seen the hostmask used (nor do I really understand what it
does).  The connection class is numeric, and defined in the Y-lines.<P> 
 
	<DT>D:ipmask:reason:<P> 
 
	<DD>This line is used to ban a block of IP addresses.  If a system
administrator has control over several domains, he/she may attempt to
avoid bans by changing the reverse DNS lookup on the host (a perfect
example of this is smartec.com, who has several domains and several
machines all on one Class C).  With a D:line, you can ban 205.230.73.*
(smartec) and nobody from that address space can connect, regardless of
DNS lookup.<P> 
 
	<DT>E:hostmask::username<P> 
 
	<DD>The E-line protects certain users from server bans (K-lines).
Generally operators use them to protect themselves from accidental
K-lines, but in some cases, a server run by an ISP will also use them to
protect their customers.<P> 
 
	<DT>H:remote servers permitted::hub server<P> 
 
	<DD>This defines a hub server, which is a server that may have other
servers connected behind it.  The "remote servers permitted" is usually
"*" or may have a hostmask to limit the remote connected servers to
within that mask.<P> 
 
	<DT>I:address mask:password:domain mask::connection class<P> 
 
	<DD>I-lines define what clients are allowed to connect to your
server. Additionally, they define what connection class (defined by
Y-lines) the client is placed in.  The password is usually left
blank.<P> 
 
	<DT>K:hostmask:time:username<P> 
 
	<DD>Most people already know what a K-line is, but for the record,
it's simply a ban from the server.  I have never seen a K:line with a
time field, but it allows you to define what times a client is allowed
on the server.  Generally, K-lines are added with the KLINE command on
the server, and the reason is stored as a comment in the config file.<P> 
 
	<DT>L:restricted servers::connected server:depth<P> 
 
	<DD>This is used to identify leaf depth behind a server.  The
restricted servers field is a hostmask for what servers to not allow
behind the connected server (usually this is blank).  The depth is what
depth of servers may be connected behind it.<P> 
 
	<DT>M:hostname:*:server description:default port<P> 
 
	<DD>This line sets the basic information for your server.  The
fields are pretty self-explanatory.  This is a mandatory field.<P> 
 
	<DT>N: &lt;see C:&gt;<P> 
 
	O:ident@hostname:password:nickname:connection class<BR> 
 
	o:ident@hostname:password:nickname:connection class<P> 
 
	<DD>These lines define the operators on the server.  The lower case
o-line identifies a local operator, who can do local server KILLs and
KLINE, as well as SQUIT and CONNECT their server from/to an uplink
server.  The upper case O-line is a global operator, who can
additionally do global KILLs (killing users off other servers) and SQUIT
and CONNECT any server on the network.  The connection class is as
specified in the Y-lines.<P> 
 
	<DT>P:hostmask:::port<P> 
 
	<DD>These are the ports that your server listens for connections on
(in addition to the default port set in the M-line).  The hostmask is an
optional field that allows you to specify which users may connect to
that port.<P> 
 
	<DT>Q::reason:server<P> 
 
	<DD>The Q-line specifies a server that will not be allowed to link
to the network at all (all servers must have identical Q-lines according
to the sample config file).  I have never seen this used.<P> 
 
	<DT>R:hostmask:program path:username<P> 
 
	<DD>Allows you to process access control through an external program
(provided by the server admin).  Whenever a client connects, the server
calls this external program with the user information.  The program then
responds based on whether or not the user should be granted access to
the server.  I've never seen this used either, and is probably
impractical for any server with a large client base.<P> 
 
	<DT>Y:class id:ping frequency:connect frequency:max connections:max
sendq<P> 
 
	<DD>The Y-line defines a connection class.  The class id is a number
that identifies the class, and is used in I-lines and C/N-lines to
identify which Y-line to use.  The ping frequency is the time (in
seconds) between ping requests (to verify that the connection is still
alive).  Connect frequency is the time between automatic connection
attempts for server connections (should be zero for client connection
classes).  Max connections is self explanatory.  The "sendq" is the
amount of data (in bytes) that is allowed to be pending going out to a
connection in that class before the server will close it (with a message
such as "Sendq exceeded").<BR> 
	On the 2.9.x versions of ircd, the connect frequency is replaced with
an identifier to handle cloning.  If it is a positive number, it
identifies how many clients can connect from the same hostmask.  If
negative, it identifies how many clients can connect from the same
username@hostmask.<P> 
 
</DL> 
 
	I would recommend reading the example.conf file in the ircd
distribution.  It has samples of most of these, as well as descriptions
that are probably better than mine.<P> 
 
 
<HR> 
 
<H2>VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)</H2> 
 
	There are a few commands that you can use to get information
from a server to help with opering:<P> 
 
<DL> 
 
<DT>TRACE [server|nick]<P> 
 
	<DD>The TRACE command is used to trace the path from your current
server to the specified server or user.<P> 
 
	When the destination is a server, TRACE will also return information
about current server and operator connections, incoming connections
(with negative class numbers), and the number of users in each class. 
The oper connections contain the connection class, the nickname, and
user@hostmask for the oper.  For server connections, it shows the
connection class, the number of servers behind it (followed by "S"), the
number of clients on and behind it (followed by "C"), the server name,
and what was responsible for connecting it.<P> 
 
	When the destination is a user, TRACE shows the connection class,
nickname and user@hostmask for that user.<P> 
 
<DT>STATS [letter]<P> 
 
	<DD>The STATS command returns server information.  These tend to vary
by server version, and are sometimes case sensitive.  Here are a few
that I know or use regularly:<P> 
 
<PRE> 
	?	Server connection statistics
	b	B-lines
	c	C/N-lines
	d	D-lines
	e	E-lines
	h	H/L-lines
	i	I-lines
	k	K-lines
	l	Data transfer statistics by connection
		The numeric fields are as follows:
			sendQ (outgoing message queue)
			sendM (protocol messages sent)
			sendK (total kilobytes sent)
			receiveM (protocol messages received)
			receiveK (total kilobytes received)
			time in seconds since the connection was created
	L	Same as STATS l, except shows IP address instead of host
	m	Command statistics
	o	O/o-lines
	p	Current opers online
	t	General server statistics
	u	Server uptime
	v	Server link information
	y	Y-lines
	z	More server statistics
</PRE> 
 
	If you are not currently an oper, I don't recommend going through and
testing these all at once.  Multiple STATS requests are usually viewed
as a threat to the server (some people have been known to flood a server
with STATS requests to fill up the server's sendq and cause network
splits).<P> 
 
<DT>LINKS [server mask]<P> 
 
	<DD>This shows the structure of the irc network, and is a bit useless
if you don't have a script or client that formats it for you.  Each line
contains the server name, its uplink name, the number of hops from your
server to the server, and the server description.<P> 
 
<DT>HTM<P> 
 
	<DD>The HTM command is used to view and set the high-transfer mode
threshold.  Additionally, it shows the incoming data rate, which is
useful when monitoring how you are doing when relinking to the
network.<P> 
 
</DL> 
 
<HR> 
 
<H2>IX. Server Routing and Connectivity</H2> 
 
	I'll qualify this section by saying that I am not presently a hub
operator, and have done very little in the way of connecting and
disconnecting remote server connections.  However, I have researched
this quite a bit.<P> 
 
	For my description, let's assume a network that looks something like
this:<P> 
 
<PRE> 
		A-----B----C----D
		      |         |
		E-----F         G----H
		|     |         |
		I     J----K    L----M
</PRE> 
 
	Usually when there is a problem, you first notice it by the decrease
in response time from other users.  Then you try pinging a few users and
notice that ping times are outrangeously high.  Usually with a
channel-wide ping and LINKS, you can identify where the problem
connection is.  Assuming you are on server A, you notice ping times are
fine up to server C, but everything from D and beyond is lagged.  The
first thing you do is a STATS l on server C (/stats l irc.c.com) to see
what the outgoing sendq is to server D.  Looking at just the server
entry for server D, it might look like this:<P> 
 
	211 irc.d.com[123.231.132.213] 1621588 9780 559 469469 24111 5862<P> 
 
	The sendq is the first number after the IP address, or 1621588 in
this case.  If we do a STATS y on server C (/stats y irc.c.com), we can
see what the max sendq allowed is.  Look for the connection class with
something aside from 0 in the connect frequency field (600 in this
case):<P> 
 
	218 Y:0:120:600:10:4000000<P> 
 
	So if that number reaches 4000000, server C will disconnect server
D, and you'll see everyone on the other side quit with the message "***
Quit: nick (irc.c.com irc.d.com)" or whatever.<P> 
 
	Now, if you were on server L, you would do STATS l on server D
(/stats l irc.d.com) and look for the entry for server C.  In this
scenerio, you might see<P> 
 
	211 irc.c.com[132.213.123.231] 142 8841 512 485915 21058 1234<P> 
 
	Since the sendq going from irc.d.com to irc.c.com is only 142 bytes,
it looks like a one-way lag situation (server irc.d.com is having
trouble receiving data from irc.c.com).<P> 
 
	Let's say you continue to monitor the sendq from irc.d.com to
irc.c.com (with /stats l irc.d.com from your position on server A), and
it rises from the previous 1621588 bytes to 3140419 bytes.  You could
wait it out and see if it splits or catches back up, but we'll decide to
reroute it now instead.<P> 
 
	Before you do anything, you have your clone over on server L do a
STATS c on server D (/stats c irc.d.com) to see where it can reconnect
to.  Let's say an alernative link is server F.  You now have a place to
put it, but then you need to find a port.  From your client on server L,
you do a STATS l on server D (/stats l irc.d.com) and look at what ports
it has open. Here's a couple of STATS l response lines that we are
interested in:<P> 
 
<PRE> 
	211 irc.d.com  0 30844455 1978134 15372958 794195 156641 156641 -
	211 irc.d.com[@*@*.6665]  0 702234 48662 118794 5963 156641 156641 -
	211 irc.d.com[@*@*.6666]  0 1750847 130878 547336 22204 156641 156641 -
	211 irc.d.com[@*@*.6668]  0 568644 38618 100102 4626 156641 156641 -
	211 irc.d.com[@*@*.6669]  0 701079 48973 121065 5271 156641 156641 -
</PRE> 
 
	The first line is the default port (6667), and looks like it's been
pretty busy, so let's use port 6665 to relink on instead.<P> 
 
	Now, we want to disconnect server D from server C, and then tell
server F to connect to server D on port 6665.  We will do all this from
server A. We start with the SQUIT command, which has the following
format:<P> 
 
	SQUIT server :reason<P> 
 
	So we do this:<P> 
 
	/squit irc.d.com :reroute<P> 
 
	At this point, it's a good idea to wait a minute for the servers to
process the change, and then we can relink using CONNECT, with the
following format:<P> 
 
	CONNECT server port link_server<P> 
 
	So we do this:<P> 
 
	/connect irc.d.com 6665 irc.f.com<P> 
 
	You can monitor the reconnect status with STATS l on irc.f.com,
though in most cases, a good connect will take less than a minute.<P> 
 
	If you are opering from a leaf server (like I do now), then you will
generally only SQUIT and CONNECT locally to your uplink.  So you have
the following network:<P> 
<PRE> 
	A----B----C
	          |
	     D----E
</PRE> 
 
	And you are on server A, with real lag to the network, then you can
reroute yourself to server D with:<P> 
 
<PRE> 
	/squit irc.b.com :reroute
	/connect irc.d.com [port]
</PRE> 
 
	My previous discussion should carry over to help with evaluation of
the connection between server A and server B.<P> 
 
	One last issue regarding server connectivity is "juping".  When a
server is having problems or has been compromised, and an admin for the
server is not available, the server can be prevented from relinking by
putting a fake server connection to the network in its place.  When the
server attempts to link, the network sees it as already being connected
and rejects the server connection.<P> 
 
<HR> 
 
<H2>X. Other Server Commands (REHASH, RESTART, and DIE)</H2> 
 
	These are a few commands you won't use often unless you are
responsible for administration of the server or need to handle an
emergency.<P> 
 
<DL> 
 
	<DT>REHASH<P> 
 
	<DD>The REHASH command simply tells the server to reload its
configuration file.  This must be done for changes to ircd.conf to take
effect.<P> 
 
	<DT>RESTART<P> 
 
	<DD>This command completely shuts down the server and restarts
it.  All connections will be closed (including yours).<P> 
 
	<DT>DIE<P> 
 
	<DD>This shuts the server down.  Generally this is done when
restarting the system the server is running on.<P> 
 
</DL> 
 
<HR> 
 
<H2>XI. Operator Communications (WALLOPS and OPERWALL)</H2> 
 
	The WALLOPS (and OPERWALL) command is used to send a broadcast
message to all operators across the network.  Oper wallops were
originally publically visible and intended to be used for disaster
announcements and the like, but have been abused to the point where now
they are operator only.<P> 
 
	The format for both commands are:<P> 
 
<BLOCKQUOTE> 
	WALLOPS :message text<BR> 
	OPERWALL :message text<BR> 
</BLOCKQUOTE> 
 
	When you do a remote CONNECT or SQUIT, the server sends out an
automatic WALLOPS announcing your action.<P> 
 
 
<HR> 
 
<H2>XII. Linking New Servers</H2> 
 
	Everyone seems to want to link a new server, mostly because of the
ego boost of being a server admin on a large irc network, and
occasionally because they want to provide it as a service to a customer
base.<P> 
 
	These are some of the issues that face new servers:<P> 
 
<DL> 
 
	<DT>Link Speed<P> 
 
	<DD>The minimum link speed to get a link is usually T1 (1.544 mbps) to a
major backbone provider.  Even this is often considered inadequate.<P> 
 
	<DT>Server Requirements<P> 
 
	<DD>The server must be running some flavor of Unix.  Unix was
designed around networking and generally can handle far more than other
operating systems can.  Whether this is true or not isn't the issue -
it's completely based on the opinions of existing hub admins (which I
happen to agree with on this issue).<P> 
 
	The ircd process generally can take between 30 and 60 megs of memory
when running on EFnet, so 64 megs is probably the minimum there.  No
other real processes should be running on the machine.<P> 
 
	<DT>Existing IRC Users<P> 
 
	<DD>To get a link, you should probably be averaging about 30
users at any given time from your domain.  This can vary, and may not be
a serious requirement if you have excellent connectivity.<P> 
 
	<DT>Operators<P> 
 
	<DD>Your list of potential operators can affect your ability to
link. If you have known abusers as operators on your server, you
probably won't get a link.<P> 
 
	<DT>Politics<P> 
 
	<DD>What it all really comes down to is whether or not you know
and are liked by the hub admins.  If they don't like you, I'd recommend
pursuing golf as a hobby instead. :)<P> 
 
</DL> 
 
<HR> 
 
<H2>XIII. Attitude and Perspective</H2> 
 
	The fact is, this is IRC.  It's a chat network - a social gathering.
Don't build your self image based on what other people think of you, on
or off IRC.  If you come on IRC because it's more important to you than
blood, you should probably invest some money in counseling.  Don't get
all emotional over what happens on here.<P> 
 
<HR> 
 
	I hope that this document has helped someone out there.  I wrote it
to appeal to the average user, not to other operators.  If you can think
of anything more I should cover, or if you want to send me hatemail (or
maybe even a nice comment), please feel free.<P> 
 
<B>Aaron Brinton</B><BR> 
<!-- was aaronb@telanis.com now aaronb at blackcloak.org --> 
former <A HREF="http://www.efnet.org/">EFnet</A> Operator (irc.ionet.net, irc.uci.edu)<P> 
 
	Special thanks to <B>Ruth Mullen</B> for many
suggestions and saving me from some grossly embarrassing grammatical
mistakes. :)<P> 
	</body>
</html>